Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

housekeeping: Update react-router monorepo to v6.14.1 #2733

Closed
wants to merge 1 commit into from
Closed

housekeeping: Update react-router monorepo to v6.14.1 #2733

wants to merge 1 commit into from

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Jul 17, 2023

Mend Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
react-router 6.0.0-beta.0 -> 6.14.1 age adoption passing confidence
react-router-dom 6.0.0-beta.0 -> 6.14.1 age adoption passing confidence

Release Notes

remix-run/react-router (react-router)

v6.14.1

Compare Source

Patch Changes
  • Fix loop in unstable_useBlocker when used with an unstable blocker function (#​10652)
  • Fix issues with reused blockers on subsequent navigations (#​10656)
  • Updated dependencies:

v6.14.0

Compare Source

Patch Changes
  • Strip basename from locations provided to unstable_useBlocker functions to match useLocation (#​10573)
  • Fix generatePath when passed a numeric 0 value parameter (#​10612)
  • Fix unstable_useBlocker key issues in StrictMode (#​10573)
  • Fix tsc --skipLibCheck:false issues on React 17 (#​10622)
  • Upgrade typescript to 5.1 (#​10581)
  • Updated dependencies:

v6.13.0

Compare Source

Minor Changes

  • Move React.startTransition usage behind a future flag to avoid issues with existing incompatible Suspense usages. We recommend folks adopting this flag to be better compatible with React concurrent mode, but if you run into issues you can continue without the use of startTransition until v7. Issues usually boils down to creating net-new promises during the render cycle, so if you run into issues you should either lift your promise creation out of the render cycle or put it behind a useMemo. (#​10596)

    Existing behavior will no longer include React.startTransition:

    <BrowserRouter>
  <Routes>{/*...*/}</Routes>
</BrowserRouter>

<RouterProvider router={router} />

    If you wish to enable React.startTransition, pass the future flag to your component:

    <BrowserRouter future={{ v7_startTransition: true }}>
  <Routes>{/*...*/}</Routes>
</BrowserRouter>

<RouterProvider router={router} future={{ v7_startTransition: true }}/>
Patch Changes
  • Work around webpack/terser React.startTransition minification bug in production mode (#​10588)

v6.12.1

Compare Source

Warning
Please use version 6.13.0 or later instead of 6.12.1. This version suffers from a webpack/terser minification issue resulting in invalid minified code in your resulting production bundles which can cause issues in your application. See #​10579 for more details.

Patch Changes
  • Adjust feature detection of React.startTransition to fix webpack + react 17 compilation error (#​10569)

v6.12.0

Compare Source

Minor Changes
  • Wrap internal router state updates with React.startTransition if it exists (#​10438)
Patch Changes

v6.11.2

Compare Source

Patch Changes
  • Fix basename duplication in descendant <Routes> inside a <RouterProvider> (#​10492)
  • Updated dependencies:

v6.11.1

Compare Source

Patch Changes
  • Fix usage of Component API within descendant <Routes> (#​10434)
  • Fix bug when calling useNavigate from <Routes> inside a <RouterProvider> (#​10432)
  • Fix usage of <Navigate> in strict mode when using a data router (#​10435)
  • Updated dependencies:

v6.11.0

Compare Source

Patch Changes
  • Log loader/action errors to the console in dev for easier stack trace evaluation (#​10286)
  • Fix bug preventing rendering of descendant <Routes> when RouterProvider errors existed (#​10374)
  • Fix inadvertent re-renders when using Component instead of element on a route definition (#​10287)
  • Fix detection of useNavigate in the render cycle by setting the activeRef in a layout effect, allowing the navigate function to be passed to child components and called in a useEffect there. (#​10394)
  • Switched from useSyncExternalStore to useState for internal @remix-run/router router state syncing in <RouterProvider>. We found some subtle bugs where router state updates got propagated before other normal useState updates, which could lead to footguns in useEffect calls. (#​10377, #​10409)
  • Allow useRevalidator() to resolve a loader-driven error boundary scenario (#​10369)
  • Avoid unnecessary unsubscribe/resubscribes on router state changes (#​10409)
  • When using a RouterProvider, useNavigate/useSubmit/fetcher.submit are now stable across location changes, since we can handle relative routing via the @remix-run/router instance and get rid of our dependence on useLocation(). When using BrowserRouter, these hooks remain unstable across location changes because they still rely on useLocation(). (#​10336)
  • Updated dependencies:

v6.10.0

Compare Source

Minor Changes

  • Added support for Future Flags in React Router. The first flag being introduced is future.v7_normalizeFormMethod which will normalize the exposed useNavigation()/useFetcher() formMethod fields as uppercase HTTP methods to align with the fetch() behavior. (#​10207)

    • When future.v7_normalizeFormMethod === false (default v6 behavior),
      • useNavigation().formMethod is lowercase
      • useFetcher().formMethod is lowercase
    • When future.v7_normalizeFormMethod === true:
      • useNavigation().formMethod is uppercase
      • useFetcher().formMethod is uppercase
Patch Changes
  • Fix route ID generation when using Fragments in createRoutesFromElements (#​10193)
  • Updated dependencies:

v6.9.0

Compare Source

Minor Changes

  • React Router now supports an alternative way to define your route element and errorElement fields as React Components instead of React Elements. You can instead pass a React Component to the new Component and ErrorBoundary fields if you choose. There is no functional difference between the two, so use whichever approach you prefer 😀. You shouldn't be defining both, but if you do Component/ErrorBoundary will "win". (#​10045)

    Example JSON Syntax

    // Both of these work the same:
const elementRoutes = [{
  path: '/',
  element: <Home />,
  errorElement: <HomeError />,
}]

const componentRoutes = [{
  path: '/',
  Component: Home,
  ErrorBoundary: HomeError,
}]

function Home() { ... }
function HomeError() { ... }

    Example JSX Syntax

    // Both of these work the same:
const elementRoutes = createRoutesFromElements(
  <Route path='/' element={<Home />} errorElement={<HomeError /> } />
);

const componentRoutes = createRoutesFromElements(
  <Route path='/' Component={Home} ErrorBoundary={HomeError} />
);

function Home() { ... }
function HomeError() { ... }

  • Introducing Lazy Route Modules! (#​10045)

    In order to keep your application bundles small and support code-splitting of your routes, we've introduced a new lazy() route property. This is an async function that resolves the non-route-matching portions of your route definition (loader, action, element/Component, errorElement/ErrorBoundary, shouldRevalidate, handle).

    Lazy routes are resolved on initial load and during the loading or submitting phase of a navigation or fetcher call. You cannot lazily define route-matching properties (path, index, children) since we only execute your lazy route functions after we've matched known routes.

    Your lazy functions will typically return the result of a dynamic import.

    // In this example, we assume most folks land on the homepage so we include that
// in our critical-path bundle, but then we lazily load modules for /a and /b so
// they don't load until the user navigates to those routes
let routes = createRoutesFromElements(
  <Route path="/" element={<Layout />}>
    <Route index element={<Home />} />
    <Route path="a" lazy={() => import("./a")} />
    <Route path="b" lazy={() => import("./b")} />
  </Route>
);

    Then in your lazy route modules, export the properties you want defined for the route:

    export async function loader({ request }) {
  let data = await fetchData(request);
  return json(data);
}

// Export a `Component` directly instead of needing to create a React Element from it
export function Component() {
  let data = useLoaderData();

  return (
    <>
      <h1>You made it!</h1>
      <p>{data}</p>
    </>
  );
}

// Export an `ErrorBoundary` directly instead of needing to create a React Element from it
export function ErrorBoundary() {
  let error = useRouteError();
  return isRouteErrorResponse(error) ? (
    <h1>
      {error.status} {error.statusText}
    </h1>
  ) : (
    <h1>{error.message || error}</h1>
  );
}

    An example of this in action can be found in the examples/lazy-loading-router-provider directory of the repository.

    🙌 Huge thanks to @​rossipedia for the Initial Proposal and POC Implementation.

  • Updated dependencies:

Patch Changes
  • Fix generatePath incorrectly applying parameters in some cases (#​10078)
  • Improve memoization for context providers to avoid unnecessary re-renders (#​9983)

v6.8.2

Compare Source

Patch Changes

v6.8.1

Compare Source

Patch Changes
  • Remove inaccurate console warning for POP navigations and update active blocker logic (#​10030)
  • Updated dependencies:

v6.8.0

Compare Source

Patch Changes

v6.7.0

Compare Source

Minor Changes
  • Add unstable_useBlocker hook for blocking navigations within the app's location origin (#​9709)
Patch Changes
  • Fix generatePath when optional params are present (#​9764)
  • Update <Await> to accept ReactNode as children function return result (#​9896)
  • Updated dependencies:

v6.6.2

Compare Source

Patch Changes
  • Ensure useId consistency during SSR (#​9805)

v6.6.1

Compare Source

Patch Changes

v6.6.0

Compare Source

Patch Changes

v6.5.0

Compare Source

This release introduces support for Optional Route Segments. Now, adding a ? to the end of any path segment will make that entire segment optional. This works for both static segments and dynamic parameters.

Optional Params Examples

  • <Route path=":lang?/about> will match:
    • /:lang/about
    • /about
  • <Route path="/multistep/:widget1?/widget2?/widget3?"> will match:
    • /multistep
    • /multistep/:widget1
    • /multistep/:widget1/:widget2
    • /multistep/:widget1/:widget2/:widget3

Optional Static Segment Example

  • <Route path="/home?"> will match:
    • /
    • /home
  • <Route path="/fr?/about"> will match:
    • /about
    • /fr/about
Minor Changes
  • Allows optional routes and optional static segments (#​9650)
Patch Changes
  • Stop incorrectly matching on partial named parameters, i.e. <Route path="prefix-:param">, to align with how splat parameters work. If you were previously relying on this behavior then it's recommended to extract the static portion of the path at the useParams call site: (#​9506)
// Old behavior at URL /prefix-123
<Route path="prefix-:id" element={<Comp /> }>

function Comp() {
  let params = useParams(); // { id: '123' }
  let id = params.id; // "123"
  ...
}

// New behavior at URL /prefix-123
<Route path=":id" element={<Comp /> }>

function Comp() {
  let params = useParams(); // { id: 'prefix-123' }
  let id = params.id.replace(/^prefix-/, ''); // "123"
  ...
}

v6.4.5

Compare Source

Patch Changes

v6.4.4

Compare Source

Patch Changes

v6.4.3

Compare Source

Patch Changes
  • useRoutes should be able to return null when passing locationArg (#​9485)
  • fix initialEntries type in createMemoryRouter (#​9498)
  • Updated dependencies:

v6.4.2

Compare Source

Patch Changes
  • Fix IndexRouteObject and NonIndexRouteObject types to make hasErrorElement optional (#​9394)
  • Enhance console error messages for invalid usage of data router hooks (#​9311)
  • If an index route has children, it will result in a runtime error. We have strengthened our RouteObject/RouteProps types to surface the error in TypeScript. (#​9366)
  • Updated dependencies:

v6.4.1

Compare Source

Patch Changes

v6.4.0

Compare Source

Whoa this is a big one! 6.4.0 brings all the data loading and mutation APIs over from Remix. Here's a quick high level overview, but it's recommended you go check out the docs, especially the feature overview and the tutorial.

New APIs

  • Create your router with createMemoryRouter
  • Render your router with <RouterProvider>
  • Load data with a Route loader and mutate with a Route action
  • Handle errors with Route errorElement
  • Defer non-critical data with defer and Await

Bug Fixes

  • Path resolution is now trailing slash agnostic (#​8861)
  • useLocation returns the scoped location inside a <Routes location> component (#​9094)

Updated Dependencies

v6.3.0: [email protected]

Compare Source

What's Changed

New Contributors

Full Changelog: remix-run/react-router@v6.2.2...v6.3.0

v6.2.2

Compare Source

What's Changed

🐛 Bug Fixes
  • Fixed nested splat routes that begin with special URL-safe characters (#​8563)
  • Fixed a bug where index routes were missing route context in some cases (#​8497)

New Contributors

Full Changelog: remix-run/react-router@v6.2.1...v6.2.2

v6.2.1

Compare Source

This release updates the internal history dependency to 5.2.0.

Full Changelog: remix-run/react-router@v6.2.0...v6.2.1

v6.2.0

Compare Source

🐛 Bug fixes

  • Fixed the RouteProps element type, which should be a ReactNode (#​8473)
  • Fixed a bug with useOutlet for top-level routes (#​8483)

✨ Features

  • We now use statically analyzable CJS exports. This enables named imports in Node ESM scripts (See the commit).

New Contributors

Full Changelog: remix-run/react-router@v6.1.1...v6.2.0

v6.1.1

Compare Source

In v6.1.0 we inadvertently shipped a new, undocumented API that will likely introduce bugs (#​7586). We have flagged HistoryRouter as unstable_HistoryRouter, as this API will likely need to change before a new major release.

Full Changelog: remix-run/react-router@v6.1.0...v6.1.1

v6.1.0

Compare Source

🐛 Bug fixes

  • Fixed a bug that broke support for base64 encoded IDs on nested routes (#​8291)

✨ Features

  • <Outlet> can now receive a context prop. This value is passed to child routes and is accessible via the new useOutletContext hook. See the API docs for details. (#​8461)
  • <NavLink> can now receive a child function for access to its props. (#​8164)

💅 Enhancements

  • Improved TypeScript signature for useMatch and matchPath. For example, when you call useMatch("foo/:bar/:baz"), the path is parsed and the return type will be PathMatch<"bar" | "baz">. (#​8030)
  • A few error message improvements (#​8202)

New Contributors

Full Changelog: remix-run/react-router@v6.0.1...v6.1.0

v6.0.2

Compare Source

✨ Features

  • Added the reloadDocument prop to <Link>. This allows <Link> to function like a normal anchor tag by reloading the document after navigation while maintaining the relative to resolution.

🗒️ Docs

  • Fixed several issues in docblocks and the docs themselves. See the full changelog for the deets!

🤝 New Contributors

Full Changelog

v6.0.1

Compare Source

🐛 Bug Fixes

  • Add a default <StaticRouter location> value (#​8243)
  • Add invariant for using <Route> inside <Routes> to help people make the change (#​8238)

v6.0.0

Compare Source

React Router v6 is here!

Please go read our blog post for more information on all the great stuff in v6 including notes about how to upgrade from React Router v5 and Reach Router.

v6.0.0-beta.8

Compare Source

Remember last week when we said

We anticipate this will be the last beta release before v6 stable next week.

Yeah, about that … 😅

We found and squashed a few high-priority bugs that needed to be addressed first. But it's coming very soon, we promise! In the mean time, here's what you'll get from our eight-est and greatest beta release:

🐛 Bug Fixes

  • We fixed a few bugs in useHref that resulted in the incorrect resolved value in cases where a basename is used on the <Router /> component (See #​8133 and #​8142 for details).
  • We also fixed a bug in our path ranking algorithm so that splat routes (routes with a * path value) are now correctly ranked ahead of layout routes.

🗒️ Docs

We've added lots of goodies to our docs and examples, and there's a lot more yet to come. Take a look and see if you find something that makes your work a little easier! We think the lazy loading and custom query parsing examples are particularly cool! 🤓

v6.0.0-beta.7

Compare Source

In this release we made a small but significant change to how <Link to=".."> works. This is going to help out a lot if you were trying to use links in a * route.

We have also backed out our blocking/prompt APIs for the stable v6 release. We will revisit this post 6.0 when we have a little more time to get it right.

✨ Features

The major change in this release could also be classified as a bugfix or a breaking change, depending on how you look at it. We essentialy altered the way <Link to=".."> works. See #​8086 for the motivation behind this change.

You'll probably want to reread the section in the v5 => v6 migration guide about <Link to> values (it has been updated), but it basically boils down to this: any leading .. segment in a <Link to> value traverses "up" one route and builds upon that route's path instead of just removing one URL segment. This feature really completes the story of relative routes and links.

We could consider this a bugfix, since this is how it was always intended to work in the first place. Without it, you'd have a difficult time linking predictably in * routes because your <a href> would be different depending on the number of segments in the current URL.

The reason this could also be considered a breaking change is that .. now works slightly differently in <Link to> than it would in <a href>. When you have <a href=".."> it operates on the URL pathname, removing one segment of the current URL. However, since many routes really only match a single segment of the URL, there is often no difference between <Link to=".."> and <a href="..">.

💔 Breaking Changes

  • We removed useBlocker(), usePrompt(), and <Prompt> for now. We will revisit these post 6.0 when we have more time to get it right. But we don't want it to block (see what I did there) the release of all the other awesome stuff we've got in v6.

🛠 Roadmap

We anticipate this will be the last beta release before v6 stable next week. Please give it a shot and let us know how it goes!

👍 Upgrading

If you're thinking about upgrading to v6, I published a few notes this past week that may help you:

Both of those posts contain steps you can take today in your v5 app without upgrading to v6.

We are also developing a backwards compat lib that should help some of you upgrade from v5 to v6. We'll post more about this when it's ready.

💻 Installing

Development for v6 has switched from dev to the main branch.

If you'd like to test it out, install from npm:

$ npm install history react-router-dom@next

v6.0.0-beta.6

Compare Source

No big enhancements in this release, just squashing bugs and writing lots of tests! Also, we are hard at work on cranking out examples for v6. See the end of this post for an update on our roadmap between here and v6 stable.

🧰 Examples

We have begun creating some examples for v6 that we hope will help developers make effective use of all the new features we have. So far, we have examples for the following:

  • Basic Example – A basic client-side app for v6 showing how to use nested routes, layouts, links, and the new <Outlet> API
  • Auth Example – Demonstrates an authentication flow including using the new useNavigate() hook, the <Navigate> element, and location.state
  • Search Params Example – Demonstrates how to build a simple search form that uses the new useSearchParams() hook
  • SSR Example – A server-rendered app that uses <StaticRouter> on the server and uses a <BrowserRouter> with ReactDOM.hydrate() on the client

Each example includes a button in the README that allows you to instantly launch a running instance on StackBlitz that you can play with. We hope you enjoy exploring!

🐛 Bugfixes

  • Make <NavLink> match only whole URL segments instead of pieces. This means that <NavLink to="/home/users"> will still be active at /home/users, but not at /home/users2. See #​7523
  • Makes "layout routes" (routes with no path) never match unless one of their children do. See #​8085
  • Fixes a route matching regression with splat routes that was introduced in beta.5. See #​8072 and #​8109
  • Fixes matching a nested splat route. See af7d038
  • Provide all parent route params to descendant <Routes>. This reverses a decision that we made in beta.5 to remove them. See #​8073

💔 Breaking Changes

  • Splats in route paths (*) match only after a / in the URL. This means that <Route path="files*"> will always match as if it were <Route path="files/*">. The router will issue a warning if your route path ends with * but not /*

🛠 Roadmap

We are very close to a stable release! The last big code changes we need to make are:

  • Fixing "linking up". Currently a <Link to=".."> operates on the URL pathname. However, this makes it difficult to link to the parent route when you're in a splat route. See #​8086. This will be a breaking change.
  • We are going to remove useBlocker() and <Prompt> in our initial v6 release, with plans to revisit them and possibly add them back at some point in the future. I still need to write up something here that explains our rationale. This will also be a breaking change.
  • We are going to add some animation primitives (see https://github.com/remix-run/react-router/discussions/8008). The <Routes location> prop will be in v6, but it isn't ideal for animation.

💻 Installing

Development for v6 is chugging along on the dev branch.

If you'd like to test it out, install from npm:

$ npm install history react-router-dom@next

v6.0.0-beta.5

Compare Source

This week's release adds some much-needed polish to a few niche features of the router: splat routes (a route that uses a * path) and basenames. It also adds a renderMatches API that completes the story for those of you who may have been using react-router-config in v4 and v5.

🐛 Bugfixes

  • A * in a child route path matches after a slash following its parent route path. This fixes some situations where the * was overly greedy (see #​7972)
  • Resolution of <Link to="."> and useResolvedPath(".") values are fixed in splat routes. Previously these resolved relative to the parent route's path. They now resolve relative to the path of the route that rendered them.

✨ Enhancements

This release makes it easier to work with apps that have multiple entry points. Using the <Router basename> prop allows React Router to be easily deployed on only a portion of a larger site by using a portion of the URL pathname (the "basename") to transparently prefix all route paths and link navigations.

For example, you can deploy one React Router app at the /inbox URL prefix, and another one at the /admin prefix. These base URLs represent two different entry points into your app, each with its own bundles. The rest of your site, including the root / URL could be rendered by something other than React Router, for example by your server framework of choice.

In the bundle for each entry point, simply initialize React Router with the basename of that entry point.

<Router basename="/inbox">
  // ...
</Router>

Then define your routes and link paths without using the /inbox URL prefix in any of them. The entire app will run relative to that prefix.

Another improvement in this release is the addition of the renderMatches API, which is the complement of matchRoutes. These APIs are both very low-level and should not normally be needed. But they are sometimes nice to use if you are doing your own data loading using the array of matches that you get back from matchRoutes.

matchRoutes and renderMatches are the equivalent of the react-router-config package we shipped in v4 and v5, just built directly into the router instead of in a separate package.

💔 Breaking Changes

  • <Routes basename> has moved to <Router basename>. This prop is also available on all router variants (<BrowserRouter>, <HashRouter>, etc.).
  • useLocation().pathname no longer includes the basename, if present.
  • The basename argument was removed from useRoutes. This reverts the signature to useRoutes(routes, location), same as it was previous to beta.4.
  • Descendant <Routes> do not get the params from their parents. This helps a set of <Routes> to be more portable by decoupling it from the params of its parents and makes it easier to know which params will be returned from useParams(). If you were relying on this behavior previously, you'll need to pass along the params manually to the elements rendered by the descendant <Routes>. See this comment for an example of how this is to be done and for a potential workaround if you really need the old behavior.
  • match.pathname in a splat route now includes the portion of the pathname matched by the *. This makes the * param behave much more like other dynamic :id-style params.
  • Resolution of relative <Link>s in splat routes is changed now because the entire pathname that was matched by that route is now different (see previous bullet). Instead of resolving relative to the portion of the pathname before the *, paths resolve relative to the full pathname that was matched by the route.

💻 Installing

Development for v6 is chugging along on the dev branch.

If you'd like to test it out, install from npm:

$ npm install history react-router-dom@next

v6.0.0-beta.4

Compare Source

Last week we released a lot of nice little bug features, but we did get a little carried away and let a little bug slip through with relative path resolution. Our bad! That nasty lil' guy is squashed in this week's beta. 🐛

And there's more! Let's dive in…

🐛 Bugfixes

  • Path resolution for nested relative routes was broken in the last release and should now be fixed. Nested routes construct their pathname based on the location of their parent, not the current location. This is explained in detail under Relative Routes and Links in our advanced guides, and the issue itself in #​8004

✨ Enhancements

  • We made some enhancements with the Params type which is now generic, so you can add your own types if you know what to expect from functions that return query parameters. (#​8019)
// before
let { valid, invalid } = useParams(); // No problems here!

let match = useMatch("profile/:userId");
let userId = match?.params.user; // wrong param, but TS doesn't know that!

// after:
let { valid, invalid } = useParams<"valid" | "key">(); // Property 'invalid' does not exist on type 'Params<"valid" | "key">'

let match = useMatch<"userId">("profile/:userId");
let userId = match?.params.user; // Property 'user' does not exist on type 'Params<"userId">'
  • Absolute nested path support

There was quite a bit of discussion in #​7335 from people who are using constants to define their route paths. In this style, paths are often written as absolute paths from the root / URL. These constants are then able to be used both in <Route path> definitions as well as <Link to> values. It usually looks something like this:

const USERS_PATH = "/users";
const USERS_INDEX_PATH = `${USERS_PATH}/`;
const USER_PROFILE_PATH = `${USERS_PATH}/:id`;

function UsersRoutes() {
  return (
    <Routes>
      <Route path={USERS_PATH} element={<UsersLayout />}>
        <Route path={USERS_INDEX_PATH} element={<UsersIndex />} />
        <Route path={USER_PROFILE_PATH} element={<UserProfile />} />
      </Route>
    </Routes>
  );
}

This style of use is now fully supported in v6. This is great for people who write their apps like this, but it technically could cause some breakage if you were using absolute paths (that start with /) in nested routes in previous betas. To fix this, simply remove the / from the beginning of any route paths that are meant to be relative. React Router will throw an error if you are using absolute paths that don't match their parent route paths. Hopefully this should help you f

Configuration

📅 Schedule: Branch creation - "every 2 week on monday" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

  • If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate. View repository job log here.

@renovate renovate bot requested a review from a team as a code owner July 17, 2023 20:32
@renovate renovate bot added the dependencies Pull requests that update a dependency file label Jul 17, 2023
@github-actions
Copy link

This PR has been marked as stale after 7 or more days of inactivity. Please have a maintainer add the on hold label if this PR should remain open. If there is no further activity or the on hold label is not added, this PR will be closed in 3 days.

@github-actions github-actions bot added the stale Issue hasn't had activity in awhile label Jul 24, 2023
@github-actions github-actions bot closed this Jul 27, 2023
@renovate
Copy link
Contributor Author

renovate bot commented Jul 27, 2023

Renovate Ignore Notification

Because you closed this PR without merging, Renovate will ignore this update (6.14.1). You will get a PR once a newer version is released. To ignore this dependency forever, add it to the ignoreDeps array of your Renovate config.

If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR.

@renovate renovate bot deleted the renovate/react-router-monorepo branch July 27, 2023 22:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
dependencies Pull requests that update a dependency file stale Issue hasn't had activity in awhile
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
0 participants